A storage system includes many components. Components may include, for example, a disk drive, a controller, a power supply unit, and an expander. An expander can be used as a conduit to connect multiple components to a single input. For example, an expander may be used to connect one or more drives to a server.
A common type of a storage expander is a Serial Attached SCSI (SAS) expander. A SAS expander accommodates the connection of one or more storage devices operating under the SAS or Serial AT Attachment (SATA) protocols. A storage expander is typically installed into an enclosure, and may include components such as a controller, power supply unit, device slot, fan, electrically erasable programmable read-only memory (EEPROM), and/or bus. A naming standard may define codes for referencing components. Some components may be defined under a standard. For example, under the SCSI Enclosure Services (SES) standard, element codes include: 02h—power-supply, 04h—temperature-sensor, and 12h—voltage sensor. Some components may not be defined under a standard. For example, the T10 SES-3 standard does not define an electrically erasable programmable read-only memory (EEPROM) component, and a vendor assigns a private type that is within a vendor-defined range under the T10 specification.
A storage expander component may include one or more sensors. For example, a standard power supply has temperature, current, and voltage sensors. A sensor may be used to detect an error in a component. A component may experience a hardware and/or software error. For example, a component of an expander may overheat, or software running on a component of a expander may time out. Expander components made by different vendors may define different properties to report internal component errors. An expander component may report an internal component error along with a standard-defined component. Commonly, if multiple vendor components are reporting to a host, host diagnostics software may have to define a separate component resource to capture such errors and apply vendor-unique error handling and management.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.